The present disclosure relates generally to the field of analyzing logs to yield meaningful insights and/or data.
In computing, a log is a file that records events taking place in the execution of a system in order to provide an audit trail that can be used to: (i) understand the activity of the system; and/or (ii) diagnose problems. Conventionally, logs can help people develop insight into the activities of complex computer systems, particularly in the case of applications with little user interaction (such as server applications). Sometimes log file entries from multiple sources are considered combined. This approach, in combination with statistical analysis, may yield correlations between seemingly unrelated events on different servers. Many operating systems and computer programs include some form of logging subsystem.
Logs may be voluminous and/or presented in a form and format that is difficult to understand. Conventionally, these logs are subjected to “log analysis” in order to help gain insights from them. This is often conventionally done using special log analysis software.
Most databases maintain some kind of transaction log. Unlike the logs described above, these logs are not mainly intended as an audit trail for later analysis, and are not (easily) human-readable. Instead, they record changes to the stored data to allow the database to recover from crashes or other errors and maintain the stored data in a consistent state. Most database systems have both a log in the general sense described above, and a transaction log. Log files are globalized content and applications typically generate logs in the language local at the location of the system in which the application is running. This helps administrators read the log files in the local language. Conventionally, content and/or knowledge, associated with log analysis, is built based on the languages that the application supports in order to be able to process the logs consistently across all languages. Log analytics or stream-based analytics systems typically use: (i) annotations that run rules to extract useful and/or relevant information from the log; (ii) annotations that run rules to identify patterns and add additional information to content being processed; and (iii) evaluation rules that identify patterns and detect particular situations that might be of interest from a problem analysis scenario.
A “resource bundle” is a file that contains locale-specific data that is helpful for using a generic piece of software specifically in a certain locale. It is a way of “internationalizing” a generic piece of software by making the code locale-independent. Extracting locale-sensitive objects such as strings from the code (as opposed to hard-coding them) means that: (i) the application can handle multiple locales without having to write different code for each locale; and (ii) human translators can deal with just the translatable text and not the programming code. It is known to provide logging software with one or more resource bundles. Conventionally, these resource bundles are used to generate the non-runtime portion of the content of the log in a local language. Herein, “non-runtime” means system/environment independent, which is to say log content strings that are mostly static and designed at development time. On the other hand, run-time log content values and/or strings are related to the environment or runtime (to name some examples, hostname, ip (Internet protocol) address, environment variable value, program runtime values). The runtime values can be numerical or non-numerical in nature. However, the non-runtime values generally include text that people expect to be presented in their preferred human-readable language.